過渡至生產環境：部署思維
本模組作為最後一環，彌合了成功研究（在筆記本中達成高準確率）與可靠執行之間的差距。部署是將PyTorch模型轉化為一個極簡、自包含服務，能以低延遲高效地向終端用戶提供預測服務，並具備高可用性。
1. 產出思維的轉變
Jupyter筆記本的探索式環境具有狀態且對生產環境而言相當脆弱。我們必須將原始的探索性腳本重構為結構化、模組化的元件，使其適合處理併發請求、資源優化，並可順利整合至更大的系統之中。
低延遲推論：持續將預測時間控制在目標閾值以下（例如 $50\text{ms}$），對於即時應用至關重要。
高可用性：設計服務時應確保其穩定、無狀態，並能在故障後迅速恢復。
可重現性：確保部署的模型與環境（依賴項、權重、設定）與已驗證的研究結果完全一致。
重點：模型服務
我們不應部署完整的訓練腳本，而是部署一個極簡、自包含的服務封裝。此服務只需處理三項任務：載入最佳化的模型檔案、執行輸入前處理，以及執行前向傳播以返回預測結果。
終端機bash — uvicorn-service
> 已準備就緒。點選「模擬部署流程」開始執行。
>
資產檢視器即時
模擬流程以檢視已載入的生產環境資產。
問題 1
哪項特性使Jupyter筆記本不適合用於生產環境部署？
問題 2
在部署前將PyTorch模型轉換為TorchScript或ONNX的主要目的是什麼？
問題 3
設計生產環境API時，何時應載入模型權重？
挑戰：定義最小化服務
規劃低延遲服務的結構需求。
您需要部署一個複雜的影像分類模型（$1\text{GB}$），該模型需要特殊的影像前處理。服務每秒必須處理$50$個請求。
步驟 1
為了確保高吞吐量與低平均延遲，針對Python腳本最關鍵的結構性改變是什麼？
解答：
將程式碼重構為獨立的模組（前處理、模型定義、推論執行者），並確保整個流程可打包以進行容器化。
將程式碼重構為獨立的模組（前處理、模型定義、推論執行者），並確保整個流程可打包以進行容器化。
步驟 2
除了訓練好的權重外，最少必要寄送的「資產」是什麼？
解答：
用於前處理的精確程式碼/類別定義，以及模型架構定義，經過序列化並與權重結合。
用於前處理的精確程式碼/類別定義，以及模型架構定義，經過序列化並與權重結合。